FIG. 1 is a schematic block diagram of a distributed network processing system 100. System 100 includes a control point (CP) 105 that is communicated to one or more network processors (NP) 110 by a switch 115. CP 105 communicates to the NPs 110 by use of messages sent through switch 115. Each message is marked with a destination address that is used by switch 115 to route the message. The destination address may be a unicast address or a multicast address. A unicast address identifies a single destination while a multicast address identifies one or more destinations. Switch 115 has a lookup table with an entry for each multicast address that indicates the members of the multicast set.
CP 105 includes a number of software components. There is a layer of software referred to as the Network Processor Application Services (NPAS) in CP 105 that provides services to User Applications to control NPs 110. An application programming interface (API) exists between the NPAS and the user application. The user application defines programming calls and returns that are used to communicate with the NPAS. A management application 120 learns about each NP 115 through the NPAS. For example, the hardware version and the software version of each NP 115 is provided to management application 120 by the NPAS. A user is thereby enabled to know which level of hardware and software exists for each NP 110.
The NPAS often is divided into multiple components, for example a first component 125, a second component 130 and a controller 135, with each of the components controlling a different NPAS function coordinated by control 135. For example, component 125 may control an internet protocol (IP) function and component 130 may control a multi-protocol layer switch (MPLS) function. The components are often independent but are able to share common utilities within the NPAS.
The components take requests from the user application, process those requests, build messages based upon the requests and issue the messages to the appropriate NP or NPs. The appropriate NPs are indicated by the application through use of an address parameter in an API call. The address in the address parameter is often the same address used by the switch to direct the messages to the appropriate NP or NPs as it may be a unicast or a multicast address.
FIG. 2 is a schematic process flow diagram for a processing operation 200 of the NPAS shown in FIG. 1. Processing operation 200 begins with an API call 205 from an application. Processing operation 200 first checks the call inputs for validity at step 210. After step 210, processing operation 200 processes the call inputs at step 215. This processing step 215 includes performing calculations or consulting internal data structures. Next at step 220, processing operation 200 builds an appropriate message according to the processing results. The appropriate message is then sent to the appropriate NPs in step 225 and control is returned to the application.
In a homogeneous network environment in which all the NPs all have the same or equivalent versions the processing operation of FIG. 2 operates satisfactorily. However, in a heterogeneous environment in which one or more NPs having a different or nonequivalent version are introduced into the network system a problem can arise. For purposes of this discussion, a different version of an NP is having a different hardware level or operating with a different software level as compared to a reference NP. An NP of a different version may require different messages or different message formats or have different functional capabilities as compared to the reference NP. For purposes of this discussion, an equivalent version for an NP as compared to a reference NP is one having a different version but the messages, the formats of these messages and the functional capabilities are the same for purposes of a particular API call or other relevant metric.
When the versions of the NPs are nonequivalent, the NPAS components need to perform different processing and send different messages and/or different message formats to various subsets of NPs as a result of a single API call. It is desirable to allow the processing overhead and burdens consequent to heterogeneous networks to be virtually transparent to any user application. What is needed is a solution that (a) reduces/minimizes an impact on current APIs, (b) reduces/minimizes an impact on NPAS components, (c) reduces/minimizes the number of messages sent through the switch, (d) the components should be independent of a coverage algorithm and (e) the NPAS components should not have to be aware of the many versions of hardware and/or software in the network system. Specifically, in (a), user applications may not be aware of the different versions of the NPs and it is preferable that a user application be able to operate in a heterogeneous system the same as it operates in a homogeneous network and to provide a single address (unicast or multicast) indicating the entire set of targeted NPs. In (b), it is not desirable to change the components in the NPAS when one or more NPs with a different version are introduced into a system. In (c), it is desirable to use multicast whenever possible to distribute the messages in order to minimize switch bandwidth usage. For (d), it is preferable that any algorithm used for determining the messaging subsets should be a common utility or function shared by all components. And (e), it would be advantageous that any additions of a new version NP not necessitate any change to any NPAS component.
Accordingly, what is needed is a method and system for providing transparent NP messaging in a heterogeneous network. The present invention addresses such a need.